Method and apparatus for determining commission

ABSTRACT

The invention provides for a method and apparatus for determining the commission to be paid to a sales representative or sales team. Whenever a sale occurs, a Transaction describing the sale is created and inputted into the Commission system of one embodiment of the invention. Based on a set of Allocation Rules that specify the credit an individual is to receive from a Transaction, the Transactions are converted into several Allocations for individual Sales Representatives or Sales Teams. One or more Quotas specify a target or goal that must be reached to earn commission for each Sales Team. A Quota State indicates the current performance of a Sales Representative with respect to a particular Quota wihtin a particular time frame. The Quotas are used to convert the Allocations/Transactions into Quota Details that specify how to increment or decrement the Quota State. A Promotion specifies the reward or commission that is received upon attaining a desired level of performance. Once a Quota State reaches a level necessary to receive a Commission or reward as set by a specific Promotion, a ledger item indicating the amount to be paid to particular Sales Team is created. A user interface may be used to create Allocation Rules, Quotas, and Promotions that are awarded for performance over a specified time period. In this manner, a business may set up incentive plans and determine commissions easily and accurately.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] This invention relates to the field of determining the salescommission provided to sales teams and representatives.

[0003] Portions of the disclosure of this patent document containmaterial that is subject to copyright protection. The copyright ownerhas no objection to the facsimile reproduction by anyone of the patentdocument or the patent disclosure as it appears in the Patent andTrademark Office file or records, but otherwise reserves all copyrightrights whatsoever. 2. BACKGROUND ART

[0004] In modern business environments, it is commonplace to employsales representatives to market the goods and services offered for sale.Sales representatives receive compensation based on a salary, the hoursworked, and/or on the goods or services sold. When basing compensationon the goods or services sold, sales representatives receive acommission that can be based on profits, net sales, the number ofproducts sold, or some other variable.

[0005] To provide sales representatives with an incentive to sell asmuch as possible or to sell more of a desired product or products atcertain prices, sales organizations create incentive plans whereinCommissions (also referred to as Promotions) are provided or offered tothe sales representatives when specific sales goals or targets areattained during a defined time period. For example, a Promotion mayconsist of paying a bonus of $50 if a blue hammer is sold in the monthof July or paying $1 for each of the first 1000 hammers sold and $2 forany additional hammer sold in the month of July. Some incentive plansprovide for individual sales representatives to be apportioned credittowards a promotional level (such as a bronze, silver, or gold level)when a sale is made.

[0006] In addition, an incentive plan may apportion credit (towards aPromotion) to everyone on a sales representative's sales team, to therepresentative's manager, or someone other than the sales representativehimself. Providing credit to persons in a selling chain (i.e., animmediate supervisor, a manager, a senior manager, etc.) is referred toas an override or rolling up (a “roll-up”) the selling chain. Figuringout who should be apportioned credit for a sale can be complex anddifficult to administer. This is particularly true when a company hasseveral different types of sales people from direct representatives,external agents, telemarketers, to distributors and resellers. Theincreasing use of sales teams, account territory, and product managershas further complicated the management of sales crediting.

[0007] The management of a business can spend a great deal of time andmoney in developing incentive plans. In the prior art, the creation anddistribution of incentive plans is a slow process that is prone toerror. Large businesses merely print up or email a plan to retailers.The retailers add Promotions and targets to the plan and distribute theplan to the sales representatives. To calculate the payment or Promotioneach sales representative will receive, the sales information is mailedback to the businesses headquarters where the calculations anddeterminations are made. The Promotion or payment is then transmittedback to the retailer and distributed to the sales representative.Mistakes in the calculations can often be made at headquarters requiringa repetition of the entire process. Often the sales representatives donot receive a copy of the plan prior to making sales. Consequently, thesales representatives are unaware of the basis for their compensation orhow an incentive plan works until after compensation is received (whichcan occur one or two payment periods after the sales have occurred andafter the promotion's time period has expired). Such a delay defeats theunderlying purpose of an incentive plan to promote the sale ofparticular products or services (i.e., the sales representative does notknow what products or services the sales organization desires topromote).

[0008] In today's competitive environment, companies thrive (andsurvive) on the basis of being able to quickly change and evolve. Thisis especially true in the sales and marketing area where rapid businesschanges are the norm. Competitive companies cannot afford beingobligated to adhere to a static information infrastructure or a slowincentive plan process that cannot keep up with a rapidly changingbusiness environment.

[0009] In a traditional system solution, the particular business rulesare broken down into their core components, which in turn are programmedusing some computer language. The traditional system is adequate torepresent a rigid and static business problem, like a general ledger orinventory system, for example. However, the traditional system is costlywhen trying to represent a quickly changing business environment likethat of a sales organization, which role is to constantly change and toevolve to align itself to changing customer needs, market changes, saleschannels and internal business initiatives.

[0010] Retailers are often not permitted to modify or create their ownincentive plans for the sales representatives. An incentive plan canonly be selected from a list of predefined plans created at a businessheadquarters. Further, sales representatives can often manipulate anincentive plan (by their actions) to obtain additional compensationunintended by management. In addition, the ability to view and organizeinformation regarding sales transactions is unavailable or difficult inthe prior art. Thus, retailers cannot easily observe statistics such asthe products or services that are selling quickly, which sales teams orrepresentatives are selling the most, the average cost a particularproduct is being sold for, etc.

[0011] Thus, a system that quickly communicates an incentive plan tosales representatives, accurately and effectively calculatescompensation to be paid to sales representatives, and allows flexibilityto adjust an incentive plan as needed in a rapidly changing environmentis desired.

SUMMARY OF THE INVENTION

[0012] The invention provides for a method and apparatus for determiningthe commission to be paid to a sales representative or sales team.Whenever a sale occurs, a Transaction describing the sale is created andinputted into the Commission System of one embodiment of the invention.Based on a set of Allocation Rules that specify the credit an individualis to receive from a Transaction, the Transactions are converted intoone or more Allocations for individual Sales Representatives or SalesTeams.

[0013] One or more Quotas specify a target or goal that must be reachedto earn commission for each Sales Team. A Quota State indicates thecurrent performance of a Sales Representative with respect to aparticular Quota within a particular time frame. The Quotas are used toconvert the Allocations/Transactions into Quota Details that specify howto increment or decrement the Quota State.

[0014] A Promotion specifies the reward or commission that is receivedupon attaining a desired level of performance. Once a Quota Statereaches a level necessary to receive a Commission or reward as set by aspecific Promotion, a ledger item indicating the amount to be paid to aparticular Sales Team is created.

[0015] A user interface may be used to create Allocation Rules, Quotas,and Promotions that are awarded for performance over a specified timeperiod. In this manner, a business may set up incentive plans anddetermine commissions easily and accurately.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016]FIG. 1 is a block diagram of one embodiment of a computer systemcapable of providing a suitable execution environment for an embodimentof the invention.

[0017]FIG. 2 illustrates the flow of transactions and the componentsthat provide the mechanisms that govern the flow in accordance with oneembodiment of the invention.

[0018]FIG. 3 illustrates the properties of several objects in accordancewith one embodiment of the invention.

[0019]FIG. 4 illustrates one or more allocation in accordance with oneembodiment of the invention.

[0020]FIG. 5 is a screen print-out of a Rule Template Editor inaccordance with one embodiment of the invention.

[0021]FIG. 6 demonstrates a method for calculating the currentperformance of a sales representative with respect to a quota inaccordance with one embodiment of the invention.

[0022]FIG. 7 demonstrates a method for calculating the currentperformance of a sales representative with respect to a quota inaccordance with one embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0023] The invention is a method and apparatus for determiningcommission. In the following description, numerous specific details areset forth to provide a more thorough description of embodiments of theinvention. It is apparent, however, to one skilled in the art, that theinvention may be practiced without these specific details. In otherinstances, well known features have not been described in detail so asnot to obscure the invention.

[0024] Embodiment of Computer Execution Environment (Hardware)

[0025] An embodiment of the invention can be implemented as computersoftware in the form of computer readable code executed on a generalpurpose computer such as computer 100 illustrated in FIG. 1, or in theform of bytecode class files running on such a computer. A keyboard 110and mouse 111 are coupled to a bi-directional system bus 118. Thekeyboard and mouse are for introducing user input to the computer systemand communicating that user input to processor 113. Other suitable inputdevices may be used in addition to, or in place of, the mouse 111 andkeyboard 110. I/O (input/output) unit 119 coupled to bi-directionalsystem bus 118 represents such I/O elements as a printer, A/V(audio/video) I/O, etc.

[0026] Computer 100 includes a video memory 114, main memory 115 andmass storage 112, all coupled to bi-directional system bus 118 alongwith keyboard 110, mouse 111 and processor 113. The mass storage 112 mayinclude both fixed and removable media, such as magnetic, optical ormagnetic optical storage systems or any other available mass storagetechnology. Bus 118 may contain, for example, thirty-two address linesfor addressing video memory 114 or main memory 115. The system bus 118also includes, for example, a 32-bit data bus for transferring databetween and among the components, such as processor 113, main memory115, video memory 114 and mass storage 112. Alternatively, multiplexdata/address lines may be used instead of separate data and addresslines.

[0027] In one embodiment of the invention, the processor 113 is amicroprocessor manufactured by Motorola, such as the 680X0 processor ora microprocessor manufactured by Intel, such as the 80X86, or Pentiumprocessor. However, any other suitable microprocessor or microcomputermay be utilized. Main memory 115 is comprised of dynamic random accessmemory (DRAM). Video memory 114 is a dual-ported video random accessmemory. One port of the video memory 114 is coupled to video amplifier116. The video amplifier 116 is used to drive the cathode ray tube (CRT)raster monitor 117. Video amplifier 116 is well known in the art and maybe implemented by any suitable apparatus. This circuitry converts pixeldata stored in video memory 114 to a raster signal suitable for use bymonitor 117. Monitor 117 is a type of monitor suitable for displayinggraphic images.

[0028] Computer 100 may also include a communication interface 120coupled to bus 118. Communication interface 120 provides a two-way datacommunication coupling via a network link 121 to a local network 122.For example, if communication interface 120 is an integrated servicesdigital network (ISDN) card or a modem, communication interface 120provides a data communication connection to the corresponding type oftelephone line, which comprises part of network link 121. Ifcommunication interface 120 is a local area network (LAN) card,communication interface 120 provides a data communication connection vianetwork link 121 to a compatible LAN. Wireless links are also possible.In any such implementation, communication interface 120 sends andreceives electrical, electromagnetic or optical signals which carrydigital data streams representing various types of information.

[0029] Network link 121 typically provides data communication throughone or more networks to other data devices. For example, network link121 may provide a connection through local network 122 to local servercomputer 123 or to data equipment operated by an Internet ServiceProvider (ISP) 124. ISP 124 in turn provides data communication servicesthrough the world wide packet data communication network now commonlyreferred to as the “Internet” 125. Local network 122 and Internet 125both use electrical, electromagnetic or optical signals which carrydigital data streams. The signals through the various networks and thesignals on network link 121 and through communication interface 120,which carry the digital data to and from computer 100, are exemplaryforms of carrier waves transporting the information.

[0030] Computer 100 can send messages and receive data, includingprogram code, through the network(s), network link 121, andcommunication interface 120. In the Internet example, remote servercomputer 126 might transmit a requested code for an application programthrough Internet 125, ISP 124, local network 122 and communicationinterface 120. In accord with the invention, one such application isthat of determining the commission to be disbursed to a salesrepresentative.

[0031] The received code may be executed by processor 113 as it isreceived, and/or stored in mass storage 112, or other non-volatilestorage for later execution. In this manner, computer 100 may obtainapplication code in the form of a carrier wave.

[0032] Application code may be embodied in any form of computer programproduct. A computer program product comprises a medium configured tostore or transport computer readable code, or in which computer readablecode may be embedded. Some examples of computer program products areCD-ROM disks, ROM cards, floppy disks, magnetic tapes, computer harddrives, servers on a network, and carrier waves.

[0033] The computer systems described above are for purposes of exampleonly. An embodiment of the invention may be implemented in any type ofcomputer system or programming or processing environment.

[0034] Utilization of Computer Software

[0035] In one embodiment of the invention, computer software thatutilizes multiple related functions and data structures is utilized. Toencapsulate these related functions and data structures, one embodimentof the invention utilizes a standard object oriented programming (OOP)language approach. To provide an understanding of encapsulation ofrelated data structures and methods, an overview of object-orientedprogramming is provided below.

[0036] Object-Oriented Programming

[0037] Object-oriented programming is a method of creating computerprograms by combining certain fundamental building blocks, and creatingrelationships among and between the building blocks. The building blocksin object-oriented programming systems are called “objects.” An objectis a programming unit that groups together a data structure (one or moreinstance variables) and the operations (methods) that can use or affectthat data. Thus, an object consists of data and one or more operationsor procedures that can be performed on that data. The joining of dataand operations into a unitary building block is called “encapsulation.”

[0038] An object can be instructed to perform one of its methods when itreceives a “message.” A message is a command or instruction sent to theobject to execute a certain method. A message consists of a methodselection (e.g., method name) and a plurality of arguments. A messagetells the receiving object what operations to perform.

[0039] One advantage of object-oriented programming is the way in whichmethods are invoked. When a message is sent to an object, it is notnecessary for the message to instruct the object how to perform acertain method. It is only necessary to request that the object executethe method. This greatly simplifies program development.

[0040] Object-oriented programming languages are predominantly based ona “class” scheme. The class-based object-oriented programming scheme isgenerally described in Lieberman, “Using Prototypical Objects toImplement Shared Behavior in Object-Oriented Systems,” OOPSLA 86Proceedings, September 1986, pp. 214-223.

[0041] A class defines a type of object that typically includes bothvariables and methods for the class. An object class is used to create aparticular instance of an object. An instance of an object classincludes the variables and methods defined for the class. Multipleinstances of the same class can be created from an object class. Eachinstance that is created from the object class is said to be of the sametype or class.

[0042] To illustrate, an employee object class can include “name” and“salary” instance variables and a “set_salary” method. Instances of theemployee object class can be created, or instantiated for each employeein an organization. Each object instance is said to be of type“employee.” Each employee object instance includes “name” and “salary”instance variables and the “set_salary” method. The values associatedwith the “name” and “salary” variables in each employee object instancecontain the name and salary of an employee in the organization. Amessage can be sent to an employee's employee object instance to invokethe “set_salary” method to modify the employee's salary (i.e., the valueassociated with the “salary” variable in the employee's employeeobject).

[0043] A hierarchy of classes can be defined such that an object classdefinition has one or more subclasses. A subclass inherits its parent's(and grandparent's etc.) definition. Each subclass in the hierarchy mayadd to or modify the behavior specified by its parent class. Someobject-oriented programming languages support multiple inheritance wherea subclass may inherit a class definition from more than one parentclass. Other programming languages support only single inheritance,where a subclass is limited to inheriting the class definition of onlyone parent class.

[0044] An object is a generic term that is used in the object-orientedprogramming environment to refer to a module that contains related codeand variables. A software application can be written using anobject-oriented programming language whereby the program's functionalityis implemented using objects. The encapsulation provided by objects inan object-oriented programming environment may be extended to the notionof transactions, allocations, quotas, quota details, quota states, andpromotions as discussed below.

[0045] In one embodiment of the invention, a shell object mechansim isutilized to store and provide access to objects and data. Such amechanism is discussed in detail in pending U.S. patent application Ser.No. 08/931,878 entitled “Method and Apparatus for Providing PeerOwnership of Shared Objects” which is hereby incorporated by reference.

[0046] Embodiment of Object Model for Determining Commissions

[0047] One embodiment of the invention provides the ability to determineCommissions and amounts payable to sales representatives (referred to asa “Commission System”). The Commission System provides an open,extensible object model that allows the business user to define anynumber of arbitrary properties (also referred to as hierarchies orobject hierarchies) that model the structures associated with abusiness, such as a business' customers, products, and sales teams (inaddition to a default model that specifies a set of hierarchies). Theseproperties can then be used through a Commission calculation process todetermine the payment for a sales representative.

[0048] Hierarchies

[0049] One model of the invention consists of a set of five (5)components or hierarchies: Sales Representative, Product, Customer,Quota, and Plan.

[0050] Sales Representative

[0051] The Sales Representative hierarchy represents the salesorganization of a business and the person or entity that makes a sale.It can represent and may consist of individual sales representatives, orsales manager(s), a selling group/team, a retailer, or any number ofarbitrary organizations. The Sales Representative hierarchy is used torepresent the individual or group that makes a sale. “SalesRepresentative” is used interchangeably with “Sales Team” to representan individual or group of persons throughout this document. Salesteams/groups are stored in a hierarchy tree, which is used to representand manipulate different organization groups. A sales team can belong toone or several groups in the tree.

[0052] Product

[0053] The Product hierarchy represents what is being sold. A Productcan be a product idenfitication number, product group, or category, forexample. Products are similarly stored in a hierarchy tree, which can beused to represent products lines, promotional groups, regionality (wherea product is sold or built), categories, etc.

[0054] Customer

[0055] The Customer hierarchy represents the customer that a product issold to. A Customer hierarchy can represent an individual customer oraccount. Similar to Sales Representatives and Products, Customers arestored in a hierarchy tree, which in turn can represent industries,territories, regions, type of sales, and other customer segments.

[0056] Quota

[0057] A Quota, also referred to as a Performance or Bucket, defines thesales performance to track and accumulate. Quotas can be defined totrack any performance measure (units, sales volume, profit margin, etc.)over any time period (weekly, monthly, quarterly, yearly, etc.) acrossany number of sales teams (sales reps, sales teams, regions, etc.)Quotas are used to calculate bonuses and Commissions, sales tracking andother types of performance measures.

[0058] Plans

[0059] Plans define the reward for a certain performance and consists ofa collection of Promotions (also referred to as a Bonus, Commission, orCompensation). Plans are the link between performance and earnings.Promotions calculate an earnings payment based on a formula using one orseveral performance variables.

[0060] In addition to the above default hierarchies, one embodiment ofthe invention permits the creation or specification of additionalarbitrary hierarchies by a user. Additional hierarchies can representactual groups or entities (such as employees) or non-existent groupsthat may be used to collect statistics.

[0061] Processing Sales Transactions

[0062] The hierarchies defined above maintain data and methods to enablethe Commission System to efficiently and accurately process sales. FIG.2 demonstrates the processing that occurs in one embodiment of theinvention from the sale of a Product or service to payment of aCommission to a Sales Representative. The Commission Model 218 indicatesthe mechanism which governs how the processing occurs. When a sale ismade, a sales transaction 200 is input into the system. Through a set ofrules 210, Sales Representatives are apportioned or allocated credit inthe form of Allocations 202. Quotas 212 and 214 process the Allocations202 into Quota Details 204 that contain the change in the current statusof the sales representative's progress towards a Promotion. The currentstatus is also referred to as the Quota State or Quota State Performance206. The amount a Sales Representative is to receive as a result of thesales transactions is determined by a calculation in a Promotion Object216. Once determined, the amount is converted into a Ledger Item 208 anddistributed out to the Sales Representative.

[0063] To provide an understanding of how each object of the Model 218governs the commission process, each object and its affect on thetransaction flow through the Commission System/engine will be discussedin detail below.

[0064] Transactions

[0065] Transactions contain information regarding a sale and may beviewed as a line item in a sales order. Each transaction is independentfrom each other such that the order in which a transaction occurs or isentered into the system is not relevant. Referring to FIG. 2, the inputto the Commission system is a Model 218 and a set of Transactions 200.The Model 218 is static, and describes the Promotions, Products, andorganizational hierarchy referenced by the incentive program. TheTransactions 200 typically describe who sold what to whom and when. ATransaction may also answer the questions “why?”, “how many?”, and “forhow much?”. Transactions 200 may be arbitrarily extended to contain anynumber of properties and these properties may later be referenced orused by other components and hierarchies of the system. Referring toFIG. 3, a Transaction's properties may be basic types (e.g., types308-312), sub-objects (e.g., sub-objects 302-306), or basic types ofsub-objects (e.g., types 314-336). A default Transaction 200 may containproperties for a Sales Representative 302 (the Sales Representative whomade the sale), a Product 304 (what was sold), a Customer 306 (whobought the product), the Date of the Sale 308, the Unit Price 310, andQuantity sold 312.

[0066] It is often the case, however, that the person who makes the saleis not the only person who gets credit for the sale. Often, a SalesRepresentative's Manager may get credit for some portion of the sale.Alternatively, the person in charge of the product that was sold shouldget credit for the sale. Additionally, a Transaction 200 may notindicate a Sales Representative; credit may need to be decided by someset of predefined rules. Further, one person may belong to severaldifferent groups at the same time (referred to as multiple inheritance).For example, one embodiment of the invention provides the ability forJon Smith to be a member of Sales Team Blue, Sales Team Red, and SalesManager over Lucy all at the same time. In this manner, Jon may receivecredit through various sales that Jon himself did not initiate. Multipleinheritance may also be utilized to create virtual sales teams tomaintain statistics and information.

[0067] Allocations

[0068] The Commission System uses the term “Allocation” 202 to indicatecredit allocated to a single individual or group on a singlesale/Transaction. An allocation may be viewed as a Transaction that istied to a Sales Representative at a certain weight. Referring to FIG. 4,an Allocation 202 may be an object that references the Transaction 200,a Sales Team or Representative 402 who will get credit for thatTransaction 200, and the percentage weight of credit 404 for theTransaction that the Sales Representative 402 receives. The total weightof all Allocations 202 for a single Transaction 200 does not need tototal one (1) or 100%. In FIG. 4, each allocation is represented by arow. For example, as demonstrated in FIG. 4, transaction number one mayresult in sales team blue being allocated 2% credit and John Smith, thesales representative, being allocated 100% credit. Transaction number 2may result in Mark Adams, the sales representative, being allocated 100%credit and Mark Adam's manager being allocated 3% credit.

[0069] Allocation Rules

[0070] The mechanism that decides how Allocations 202 are created fromTransactions 200 is the set of “Allocation Rules” 210. To understand howAllocation Rules 210 are written, it is best to look at the kind ofquestions an Allocation Rule 210 will need to address. For a givenTransaction 200, the following are examples of how Allocations 202 mayneed to be created. EXAMPLE I 1. If Sales Representative Joshua made thesale, give Joshua 100% credit for the sale. 2. If sales manager Eileenor anyone working under her made the sale, give Eileen 20% credit forthe sale. 3. If the color of the Product sold is “Red’, give 5% creditto ‘The Red Team’. 4. If the sale was made to any of the ‘LargeCustomers’, give John 10% credit. 5. If the number of units sold isbetween 100 and 500, give 5% credit to Brennan.

[0071] Each of the examples above represents a different type ofAllocation. To understand the use of Allocation Rules to allocatecredit, it is useful to examine the type of Allocation generically.Referring to the examples above, situation 1 is a Sales Team or SalesRepresentative type of Allocation wherein a Sales Representative, Josh,is allocated credit for a Transaction. Situation 2 is a Roll-up type ofAllocation wherein a Sales Manager, Eileen, is allocated credit for aTransaction made by another person. The Transaction is rolled-up theselling chain to the sales manager, Eileen. Situation 3 is a property ofa product type of transaction wherein a property of a product, thecolor, is being utilized to allocate credit for the Transaction.Situation 4 is a property of a Customer type of transaction wherein aproperty of a customer, large customer, is utilized to allocate creditfor the Transaction. Situation 5 is a quantity in a range type ofAllocation wherein a quantity range, the number of units sold, isutilized to allocate credit for the Transaction.

[0072] It is useful to have a language that has the ability to describeeach of these conditions/situations, in any (boolean) combination. RuleTemplates may provide this ability. In one embodiment, a Rule Templateis the mechanism for describing how the user expects the rules to“look”. The Rule Template is used both in generating Allocations 202,and in filtering or determining eligible Quotas (discussed below).

[0073] A Rule Template consists of a collection of Allocation Rules 210.Each Allocation Rule 210 is represented by a Name (or number) and acollection of Rule Attributes. Each Rule Attribute corresponds to aqualitative description of one of the examples above; the Rule Attributecontains a Transaction-based Property, an Operation, and an Alias. Ifall of the conditions in Example 1 need to be handled at once, thefollowing Rule Attributes would be present in the Rule Template (Table1): TABLE 1 Property Operation Alias 1 SalesTeam = Sales Representative2 SalesTeam = Sales Manager 3 Product.Color = Color 4 Customer =Customer 5a Quantity > Quantity Min 5b Quantity < Quantity Max

[0074] Referring to FIG. 3 and Table 1, “Property” is a sub-property ofthe Transaction object 200 which will need to be referenced. This can bea “deep property”, like “Product.Color” 324, that is a property of anobject (e.g., Product 304) referenced from the Transaction 200. The“Operation” describes how to match the value, and the “Alias” is simplyhow the user interface will display this attribute. FIG. 5 is a screenshot of the Rule Template Editor user interface that allows for thecreation and modification of a Rule Template as provided by oneembodiment of the invention.

[0075] Referring to Table 1, row 1 represents a rule in which a salesrepresentative is allocated credit for a sale. The user views the personallocated credit in the Sales Representative Property as a SalesRepresentative (the alias). Row 2 represents a rule in which the SalesManager is allocated credit for a sale made by any of the SalesRepresentatives that she manages (i.e., the sales manager's children inthe SalesTeam hierarchy). The Sales Manager's children's sales arerolled up to allocate credit to the Sales Manager. This representationis similar to the representation in Row 1 but for a different personbeing allocated credit. The user views the person allocated credit inthe Sales Representative Property as the Sales Manager. Row 3 representsa rule in which the color of a product determines who is allocatedcredit. The user interface displays “Color” (the alias) that isrepresented by the Property Product.Color. Row 4 represents a type ofcustomer that is allocated credit and the user views the term“Customer”. Situation 5 of Example 1 is represented by two sets of RuleAttributes in Table 1, rows 5a and5b .Row 5a represents that theQuantity Property must be over a certain minimum for credit to beallocated. Row 5b represents that the Quantity must be less than acertain maximum for credit to be allocated. The user interface displaysthe alias Quantity Min and Quantity Max in rows 5a and 5b respectively.

[0076] Notice that a “value” is not part of a Rule Attribute; thequantitative “Joshua”, 20%, ‘Red’, etc. is missing. These values arestored in the Allocation Rules themselves. The Rule Attributes describehow the Rules “look” (i.e., a generic representation of the rules),while the Rules themselves contain the actual conditions. Thus, the RuleTemplate provides a generic representation of the types of rules thatmay be utilized by the user. By storing Rule Attributes in a RuleTemplate in this manner, a user can later create rules for allocatingcredit with other values. For example, using the Rule Attributes inTable 1 above, a user can later create a rule that specifies any type ofquantity range, product color, sales manager, sales representative, ortype of customer.

[0077] Referring to FIG. 2, a Commission Model 218 contains a collectionof Rule Sets. In one embodiment a different rule set is stored for eachSales Team or Sales Representative. A Rule Set consists of a RuleTemplate (i.e., the generic set of type of rules available), acollection of Allocation Rules 210, and the “Recipient”—the Sales Teamor Sales Representative that utilizes this particular rule set. AnAllocation Rule is “fired” when every condition of the rule is met. EachAllocation Rule consists of the allocation weight to be credited for theresulting Allocation, a collection of values, and a collection of RuleAttributes. Each value corresponds to a Rule Attribute, and the rulewill fire if all of the conditions in the Rule Attribute are met. Thus,an Allocation rule can be viewed as a set of pairs of Rule Attributesand corresponding Values. Referring to FIG. 2, for every Allocation Rule210 that fires, one Allocation 202 is created.

[0078] The rules corresponding to Example I above are illustrated inTable 2 below. Note that for figure simplicity the recipient (not shown)for all these rules is the same, since the rules are assumed to beutilized by the same Sales Team or Sales Representative. TABLE 2 SalesQuantity Quantity Sales Rep Manager Color Customer Minimum MaximumWeight 1 Joshua 1.00 2 Eileen 0.20 3 Red 0.05 4 Large 0.10 Customers 5100 500 0.05

[0079] Each rule contains conditions that must be met. In rule 1 thevalue of the Sales Representative must be “Joshua”. In Rule 2, the SalesManager value must be equal to “Eileen”. In Rule 3, the Color value mustbe “Red”. In Rule 4, the Customer value must be “Large Customers”. Thefifth rule contains two conditions which must both be met, the QuantityMinimum value must be 100 and the Quantity Maximum Value must be 500.The allocation weight column illustrates that weight that will beallocated if each condition is met.

[0080] To illustrate the above allocation rules, assume that Eileen isJoshua's Manager, and Joshua sells 400 Red Hammers to “The Large ToolStore”. In this scenario, five different Allocations will be created:(1) an allocation to Joshua for 1.00; (2) an allocation to Eileen for0.20; (3) an allocation to the Red Team for 0.05; (4) an allocation toJohn for 0.10; and (5) an allocation to Brennan for 0.05, with a totalweight of 1.4 times the original Transaction.

[0081] Quota

[0082] A Quota (also referred to as a Quota object) may be viewed as atarget that each Sales Representative is trying to reach. It is the endgoal or target that is set up in an incentive program that a SalesRepresentative must reach in order to earn the Commission. Since earninga Commission may be based on a specified time period, a Quota instanceis created for each time period desired. Further, each Quota instancecontains a collection of additional objects in the system that maintainthe current state of performance for each individual SalesRepresentative (referred to as Quota State, discussed below). Each Quotacontains four (4) distinct categories or properties that characterizethe Quota's behavior: (1) a Temporal property; (2) a PerformanceMeasure; (3) Eligibility Rules; and (4) Levels (also referred to asQuota Levels). In addition, a fifth property, Targeted, specifieswhether targets are to be set on a SalesTam by SalesTeam basis (ratherthan using the same Quota for multiple SalesTeams). The Temporalproperty provides for a time period within which the Quota is measured.The Performance Measure provides the ability to quantify a transactionand determine how much a specific transaction is worth. The EligibilityRules determine which Transactions the Quota is interested in todetermine whether a commission should or should not be paid (i.e., thestandards to reach the target). The Quota Level property provides therange(s) needed to reach or earn a commission. To better understandthese properties and their relationships, each property is discussed indetail below.

[0083] Temporal Property

[0084] A Quota is expected to accumulate statistics for somewell-defined time period, and then restart at the beginning of the nextperiod. For example, a monthly Quota would track performance forJanuary, February, etc. At the beginning of each new month, performancewould begin at zero. If a Transaction does not occur within thespecified time period, then a particular Quota is not interested in thatparticular Transaction.

[0085] There are four time-related properties: Start Date, DurationUnit, Duration Quantity, and Total Periods. The Start Date propertycontains the date the time period is to begin. The Duration Unitproperty specifies the type of time period being used (e.g., monthly,yearly, daily, etc.). The Duration Quantity property specifies how manytimes the Duration Unit property repeats for one Quota (e.g., ifUnits=Months and Quantity=2, the Quota period last for two months). TheTotal Periods property specifies how many Quota periods the calculationswill be accumulated for.

[0086] For illustrative purposes, compare a Quota which begins on Jan.1, 1998 with Quantity=2, Units=“Months”, and Periods=6; with a Quotabeginning on Jan. 1, 1998 with Quantity=1, Units=“years”, and Periods=1.Both Quotas become inactive on Jan. 1, 1999, but the first Quota willhave six bimonthly “buckets” (and will repeat and collect statistics six(6) times), while the latter will have one large bucket for the entireyear.

[0087] In another embodiment of the invention, the Temporal propertiesinclude a start date and end date. Further, multiple instances of thesame Quota object may be created and instantiated with different oroverlapping starting and ending dates. In this manner, time periods canaccumulate for a single Quota to earn a single Commission. For example,if the target is to sell 1000 hammers in January and 1000 hammers inFebruary, if Jon sells 0 hammers in January and 1200 hammers inFebruary, it may appear that Jon is entitled to earn a Commission basedon the February performance. However, by maintaining multiple instances,the system can determine that to “catch up” Jon must earn 2000 hammersby the end of February to earn any Commission. Further, in such anembodiment, the time periods can overlap. For example one time periodmay run from January 1 to February 1, while another time period for thesame Quota can run from January 15 to February 15. Allowing overlappingtime periods permits the user to accumulate statistics in variousmanners or use an increase in sales over multiple specified time periodsto determine whether a Commission is due.

[0088] When the temporal properties are applied to specific Allocationsor Transactions, a boolean result is returned. If the Transactionoccurred within the specified time period, True or 1 is returned, and ifthe Transaction occurred outside of the specified time period, False or0 is returned.

[0089] Eligibility Rules

[0090] If there is no way to describe which Transactions a Quota isinterested in, only a single Quota is needed, to count all Transactionssold. Eligibility Rules determine the Transactions that a Quota isinterested in or that a Quota will use in its determination of a whethera Sales Representative has attained the desired target. In this respect,Eligibility Rules may be viewed as a filter of Transactions. Forexample, Quota A may only be interested in how many red trucks were soldor how the top salespersons are performing. Any transaction that doesnot include information regarding red trucks or top salespersons,respectively, would not be utilized by Quota A in determining theCommission. Thus, although Eligibility Rules may appear similar toAllocation Rules, Allocation Rules create Allocations (a non-booleanresult) that determine which Sales Representative will earn credit for aparticular Transaction. Eligibility Rules determine which Transaction iseligible for a Quota to use in calculating a Commission (a booleanresult of true if the Transaction is eligible and false if theTransaction is not).

[0091] The Eligibility Rules are established and set up in the samemanner as Allocation Rules with Rule Attribute-Value pairs and do nothave specific targets associated with the rule. However, dissimilar toAllocation Rules, Eligibility Rules do not have a Sales Representativeand Weight associated with the result. Eligibility Rules contain a setof conditions. An Eligibility Rule will “fire” or return a true resultif any condition specified is met (“OR” logic is utilized). For example,assume an Eligibility Rule contains the following conditions: (1)Transactions containing “red sedans”; (2) Transactions with quantitesgreater than 2000; and (3) Transactions with blue trucks. If eithercondition (1), condition (2), or condition (3) is met, the rule will“fire” and return a true result.

[0092] Performance Measure

[0093] Once the Commission Engine knows which Transactions apply to aQuota, the Transaction must be quatified. The Performance Measure is away to quantify a transaction. The Performance Measure consists of aName of a property (in the Transaction object) and a mathematicalformula using the Transaction properties which, when evaluated, tell theQuota how much that Transaction was worth. It provides the ability toquantify and assign a number to a Transaction which may be subsequentlyused for calculations.

[0094] Example 2 illustrates some sample Performance Measures: EXAMPLE 2Name Formula 1 Units Quantity 2 Revenue Quantity * Unit Price 3 ProfitQuantity * (Unit Price − Product.MfgCost)

[0095] Referring to Example 2, Performance Measure 1 is titled Units andis equal to the Quantity property in a Transaction. Performance Measure2 is titled Revenue and is based on the Quantity in the Transaction andthe Unit Price for each item in the Transaction. Performance Measure 3is titled Profit and is based on the Quantity in the Transaction timesthe profit for a quantity of one (e.g., the price of one unit (UnitPrice)—the manufacturing cost of a product (Product.MfgCost)).Performance Measure 3, Profit, illustrates how to use a property of theProduct sold. Such a use is possible as long as “Product” is an objectproperty on Transaction, and the sub-object has a “MfgCost”(manufacturing cost) property. Similarly, Transaction must havetop-level Quantity and UnitPrice properties. Nested properties ofarbitrary depth are supported, as long as the resulting property is ofthe correct type (e.g., a number).

[0096] Consider a Transaction in which 1000 hammers were sold for $2.50each. Some Quotas may be interested in the fact that 1000 hammers weresold (total quantity), while others may be interested in the fact thatthe Transaction generated $2,500 in revenue. Various PerformanceMeasures provide the ability to quantify the Transaction in the desiredmethod. Example 2 above demonstrates three sample Performance Measures.

[0097] Quota Levels

[0098] The Quota Levels property consists of a collection of Levels. ALevel is an abstraction that specifies a range or goal that the SalesRepresentative must attain in order to earn a specific Commission. EachLevel contains a Name, a Start, and an End. Table 3 illustrates acollection of three Levels: TABLE 3 Name Start End 1. Bronze 0 3,000 2.Silver 3,000 4,000 3. Gold 4,000 Infinity

[0099] In one embodiment, Quota Levels must be non-overlapping and havenon-negative lower bounds (Starts). Table 3 illustrates that to attainthe Bronze Level, the Sales Representative must attain between 0 and3,000. To attain the Silver Level, the Sales Representative must attainbetween 3,000 and 4,000. To attain the Gold Level the SalesRepresentative must attain 4,000 or more. Table 3 illustrates a targetedQuota or a Quota that is targeted for a particular SalesTeam or SalesRepresentative.

[0100] The bounds only make sense in the context of the PerformanceMeasure; if the measure is Units, a Sales Representative must sell 3000units to reach “Silver” level, while if it is Profit, he must sell 3000dollars. It is often the case that the user will want both large andsmall Sales Teams to belong to the same Quota. But it hardly seems fairthat the smaller team must perform as well as the larger team to achievetheir goals. For this reason, it is possible to set targetsindependently for each participant in a Quota. A Quota's participant setis defined as the union of the participants of all the Promotions thatreference that Quota (Promotions are discussed below). Each QuotaLevelin a “targeted” Quota is relative to the target; that is, the upper andlower bounds will be fractions around 1.0. If a Sale Team's target is4000, Table 3 corresponds exactly with Table 4. TABLE 4 Name StartEnd 1. Bronze 0.00 0.75 2. Silver 0.75 1.00 3. Gold 1.00 Infinity

[0101] In Table 4, each bound in the Level is divided by the totaltarget amount of 4,000. Thus, the End bound for the Bronze Level andStart bound for the Silver Level is equal to 3,000/4,000 or 0.75.Similarly, the End bound for the Silver Level and Start Bound for theGold Level is equal to 4,000/4,000 or 1.0. In this manner, the fractionsmay be applied to particular Sales Teams with differing goals (e.g., agoal of 4000, 1000, or 20000) merely by multiplying each bounds fractiontimes the target. Table 4 is a non-targeted Quota that is not dependenton a particular SalesTeam but applies to any SalesTeam.

[0102] Quota State

[0103] In one embodiment of the invention, each instance of the Quotaobjects discussed above are utilized as a container for a set of QuotaStates, one for each participant (or Sales Representative). The QuotaState also contains the current up-to-the-minute performance informationfor each Sales Representative. A Quota State may contain the followingproperties: (1) Sales Representative; (2) Performance (the currentperformance of the Sales Representative); and (3) Target (what the SalesRepresentative needs to achieve).

[0104] The Performance property of a Quota State maintains the currentstatus and performance of a particular Sales Representative with respectto a particular Quota. Thus, the Performance property is dynamic andchanges as the various Transactions flow through the system.

[0105] The Target Property of a Quota State provides the total endtarget for that particular Sales Representative. As discussed above theTarget property can be multiplied against every fraction specified inthe bounds of a Quota Level to determine the number necessary for aparticular Sales Representative to attain a level. To determine thecurrent Level of a Sales Representative, the performance of a SalesRepresentative stored in the Performance property (which has not beenbroken down into fractions) is divided by the Target property. Theresult produces a fraction that can be compared to the Quota Levelproperties to determine the Sales Representative's status. For example,if the Target is 10000, and the current Performance is 2500, the currentstatus of the Sales Representative is Performance divided by Target or2500/10000=0.25. 0.25 is then compared to the Quota Level property todetermine which Level the Sales Representative has attained.

[0106] In one embodiment of the invention, the Target property canconsist of a rule instead of a constant number, to impose higher levellogic for target calculation. For example, a target may specify a rulerequiring a 3% increase over the prior year's performance.

[0107] Evaluating the interrelationships of the Transactions, Quotaobject and Quota State to determine the Performance of a SalesRepresentative may be done several ways.

[0108] One method for calculating the current Performance of a SalesRepresentative towards a specific Quota is illustrated in FIG. 6. Atstep 600, all of the Transactions that have taken place are examined. Atstep 602, all of the Allocations for each Transaction are examined. Atstep 604, each Allocation for a particular Sales Representative isidentified. At step 606 it is determined if each Transaction representedby the Allocation is within the specified time period in the Quotaobject. At step 608, it is determined if each Transaction represented bythe Allocation is eligible under the Quota Eligibility Rules. If theAllocation is eligible and in the appropriate time period, thePerformance Measure for that Transaction is multiplied by the weightaccording to the Allocation at step 610 and added to a running total ofthe Sales Representative's performance at step 612.

[0109] The following calculation represents the current state of anindividual Sales Representative with respect to a Quota in accordancewith the above method:${f\left( {Q,P,S} \right)} = {\sum\limits_{T \in {{Trans}{({Q,P})}}}{\sum\limits_{A \in {T.{Allocs}}}{{U?}\left( {{A.\quad {SalesTeam}} = S} \right)*{Q.\quad {{Eligible}?}}(T){Q.\quad {{Measure}(T)}}*{A.\quad {Weight}}}}}$

[0110] where:

[0111] Trans(Q,P)={T\T.TransDate≧I.StartDate and T.TransDate<I.EndDateand I=Q.Instances(P)

[0112] T.Allocs={Allocations associated with T}

[0113] T=T with T.SalesTeam=S $\begin{matrix}{{{U?}(x)} = \left\{ \begin{matrix}1 & {x = {true}} \\0 & {x = {false}}\end{matrix} \right.} \\{{{Q.\quad {{Eligible}?}}(x)} = \left\{ \begin{matrix}1 & {{\exists{r \in {{Q.\quad {EligibleSet}}\quad {such}\quad {that}\quad {r(x)}}}} = {true}} \\0 & {otherwise}\end{matrix} \right.}\end{matrix}$

[0114] Another way to view the process of determining the currentPerformance of an individual Sales Representative is illustrated in FIG.7. At step 700, all of the Transactions (or a set of Transactions) areentered into the system. At step 702, the Allocations for theTransactions are created. At step 704, the method iterates over eachAllocation and locates the instance of the relevant eligible Quota forthe desired time period. At step 706, a Quota Detail is created. A QuotaDetail contains the change that will result in the current Performancestate. Thus, a Quota Detail is the mechanism to track the changes in aQuota State. At step 708, the corresponding Quota State for the SalesRepresentative desired is located and the Quota Detail is added to theQuota State at step 710.

[0115] Promotions

[0116] Once the performance statistics have been accumulated in theQuota State, there needs to be a way to specify how to pay SalesRepresentatives based on their Performance. A Promotion (also referredto as a Bonus of Commission) provides that mechanism. A Promotionconsists of a reference to a single primary Quota, a collection of SalesRepresentative participants, and a collection of Promotion Rules. EachPromotion Rule, when fired, generates a Ledger Item indicating a paymentto a Sales Representative.

[0117] Promotion Rules

[0118] A Promotion Rule has two components: (1) a Quota Level predicate;and (2) a Reward Formula. When a participant's Performance reaches arule's predicted level, the rule fires, and the Sales Representativereceives credit equal to the value specified by the reward formula. Thereward formula is a mathematical formula with variables supplied by theappropriate Quota State. Table 5 demonstrates some sample PromotionRules. TABLE 5 Quota Level Reward 1 Bronze 100 2 Silver Performance * 103 Performance/Target * 9000 4 Ratio * Reward 5 Ratio &SalesTeam.Salary * 0.05 6 Rank < 5 ?(5 − Rank) * 100:0

[0119] The first rule imparts a $100 reward on a participant thatreaches the ‘Bronze’ Quota Level; that is, when a participant SalesRepresentative achieves the Bronze level, a LedgerItem is created withCredit equal to 100. If the Performance Measure of the Promotion's Quotais “Units”, then the second rule pays $10 for each item sold if theparticipant reaches the ‘Silver’ level. (If the Performance Measure is“Revenue”, however, the second rule doesn't make much sense, in that therecipient would receive ten times as much revenue as he brought in.) Anyproperty in the Quota State may be used in the Reward Formula.

[0120] A rule need not have a Quota level predicate (e.g., rules 3-6);if no predicate exists, the rule always fires. Also more than one rulein a Promotion can fire, either due to the lack of a predicate, oroverlapping Quota Levels. The third rule references both the Sale Team'sperformance and his target and creates a ratio that is multiplied timesa reward amount. Rule 3 pays on a sliding scale, in which theparticipant receives exactly $9,000 when the target is met, $4500 at 50%of the target, etc. In one embodiment, the Performance/Target ratio maybe replaced with a variable “Ratio” that can be used in its place. Forthe same reason that a user may desire to set targets individually foreach Sales Representative, it is advantageous to set the reward value($9000 here) on a participant by participant basis as well (e.g., pay alarger amount to a large sales team). For that reason, the Quota Stateobject has a “Reward” property in addition to Performance and Target.Therefore, if every Sales Representative's Reward value was equal to9000, rule 3 and rule 4 above are identical. In truth, any number ofadditional properties can be added to the Quota State object, andthereafter the properties can be used in Promotional Rules.

[0121] The participant corresponding to a Quota State is availablethrough the Quota State's “Sales Representative” property. Thus, all ofthe participant's properties are also available in the reward formula.Rule 5 demonstrates this; it rewards a Sales Representative thatachieves its target with 5% of the Representative's base salary.

[0122] In addition to the Quota State variables, four (4) types ofadditional “Rank” related variables are available for use in a RewardFormula that allow rules based on where a Sales Representative ranksrelative to other participants in the Promotion or Quota: (1) Rank: therank of a Sales Representative in a group (e.g., the most sales or thetop four sellers); (2) Quota Rank: the rank among Quotas; (3) RatioRank: the rank based on percentage sales and not raw sales; and (4)Quota Ratio Rank.

[0123] The “Rank” variable corresponds to the cardinality of the SaleTeam's raw performance compared with all the other participants of thisPromotion. Quota Rank is the same rank taken from the participants ofthe Quota, which is a superset of the Promotion's participants. RatioRank (also referred to as Percent Rank) and Quota Ratio Rank (alsoreferred to as Quota Percentage Rank) are similar rank variables thatare based on performance as a percentage of target, rather than rawperformance. Rule 6, which uses the branching operator (?:) pays $400 tothe highest ranking Sales Representative, $300 to the second, $200 tothe third, $100 to the fourth, and nothing to the rest.

[0124] The Ratio and Rank variables do not reside on the Quota Stateobject, but are supplied specifically for the Promotion Rules by theCommission System/Engine.

[0125] Multi-QuotaLevel Predicates

[0126] Incentive plans may have rules that are based on the successfulattainment of multiple goals. For example, a user may not want to give areward to a Sales Representative unless the representative sells 10,000hammers and 10,000 saws. The Quotas for 10,000 hammers and 10,000 sawsmay be stored in separate Quotas if these amounts are being utilized toattain another Promotion, for example. For this reason, a Promotion mayhave zero or more secondary Quotas, and Promotion Rules with multiplecorresponding Quota Level Predicates. TABLE 6 Primary Secondary Reward 1Bronze 0.05 * Performance 2 Silver Satisfactory 0.07 * Performance 3Gold Satisfactory 0.10 * Performance

[0127] Table 6 demonstrates some examples of multi-quota level promotionrules. A Sales Representative must achieve Silver level in the primaryQuota, and he must be Satisfactory in the secondary Quota in order toreceive a bonus of 7% of his sales. Note that if a Sales Representativehas not achieved Bronze or Satisfactory levels, he will not receive anycredit (no rule will fire).

[0128] One embodiment of the invention provides that the variables inthe reward formulae are all based on Quota States from the primary Quotaand the formula may not use performance statistics from the secondaryQuotas. Another embodiment of the invention provides full Multi-Quotasupport in which a reward formula would be able to use the Performance,Target, and Reward variables from any dependent Quota. Anotherembodiment of the invention provides the ability to set a Promotionbased on the ratio of specific products to total products (referred toas Penetration). For example, if the manufacturer does not want theSales Representative to sell too many red hammers, a ratio of 1:4 may beutilized.

[0129] Retroactive versus Point-Forward

[0130] One embodiment of the invention provides for an additionalproperty of a Promotion that affects the output of the Commission Engine(i.e., the amount paid to a Sales Representative). This property is astring or flag that indicates whether calculations are to be performedretroactively or point forward (also called incrementally). The effectof this property is best illustrated through example. Consider a simplenon-targeted monthly Quota beginning on Jan. 1, 1997, which tracks salesof hammers. This Quota has “Units” as the Performance Measure, and twoQuota Levels: Name Start End 1. Bronze 0 1000 2. Silver 1000 Infinity

[0131] Consider also a Promotion referencing this Quota; with two rules:Quota Level Reward 1. Bronze Performance 2. Silver Performance * 2

[0132] Finally, imagine that there are two eligible Allocations:TransDate Units Product SalesTeam Weight 1. Jan. 5, 1997 500 HammerJoshua 100% 2. Jan. 20, 1997 1000 Hammer Joshua 100%

[0133] A LedgerItem represents that amount paid to a SalesRepresentative and is discussed in detail below. An analysis of theLedger Items generated demonstrates varying results dependent on thetiming of the Engine execution. For example, assume that the Engine isrun once, on February first. The natural assumption would be to look atthe total performance, 1500, decide that Joshua has achieved the Silverlevel, and should therefore receive a payment of $3,000. This type ofanalysis corresponds to a “Retroactive” Promotion, in which the finallevel achieved applies retroactively to the beginning of the period. Ifthe same example is utilized but the Engine run twice, on Jan. 15, 1997,and again on Jan. 31, 1997, a different result is likely. When theEngine is first run, the total performance is 500, so a LedgerItem witha credit of $500 is generated (the Bronze level rule fires). At the endof January, the total performance is 1500, so a LedgerItem is generatedfor $2,500, which is the total $3,000 deserved minus the $500 alreadypaid out.

[0134] Point-Forward promotions specify that when a Sales Representativereaches a new Quota Level, Promotion Rules for that level only apply forsubsequent Transactions. In other words, the Sales Representative onlyachieves a reward for that portion of items sold in a specific level.Consider the example above for a Point-Forward promotion with two Engineexecutions. The first payment would still be $500, as Joshua isunambiguously within the Bronze level on Jan. 15, 1997. However, thesecond payment is difficult to determine. The case could be made forthree different amounts: $1,000 (1000 hammers sold keeping Joshua in theBronze level), $1,500 (500 hammers sold to complete the first 1000 inthe bronze level for $500 and 2*500 for the next 500 hammers sold in theSilver level), or $2,000 (1000*2 for 1000 hammers sold in the silverlevel).

[0135] The second transaction places Joshua into the Silver level. Ifthis transaction qualifies for the Silver level rule, it would generatea $2,000 Ledger Item. If this transaction does not qualify (because it“began” in the Bronze level), it would generate a $1,000 Ledger Item. Inboth of these cases, the transaction order becomes very important. Forexample, if a third transaction arrives dated Jan. 10, 1997 (out oforder), it would be necessary to process not just the new transaction,but also to reprocess the transaction from Jan, 15, 1997. It seemscounter-intuitive that two unrelated transactions have such an effect onone another.

[0136] In one embodiment, the Engine defaults to Point Forward analysisand generates the final possible answer discussed above: $1,500. Thisquantity can be determined by examining the Promotion Rules and thetotal Performance (1500 units). Of the total Performance of 1500, 1000are in the Bronze level ($1,000), and 500 are in the Silver level($1,000). Since the system has already paid out $500 from the firsttransaction, it creates a new Ledger Item for $1,500.

[0137] Ledger Items

[0138] A Ledger Item indicates the amount paid to a SalesRepresentative. Whenever a Quota Detail is created (indicating a changein Quota State performance), the Quota State, Quota Instance, andQuota's time stamp is updated with the current time. When the CommissionSystem/Engine is asked to pay a Promotion, it finds all Quota Statesthat have been changed since the Promotion was last paid. For each ofthose Quota States, the Engine calculates the total amount of creditthat should be paid to the Sales Representative, based on the QuotaState and the Promotion Rules. It is possible to determine the amount tobe paid directly from the Quota State; there is no need to examine theTransactions or Allocations which contributed to that Quota State (thisability is discussed below).

[0139] Once the total amount of money to be paid is known, the Enginefinds the amount of money which has already been paid (by querying forall Ledger Items associated with this Promotion, Sales Representative,and Period), and generates a new Ledger Item for the difference (ifnon-zero). The output of the Commission is not dependent on thefrequency that the engine is run. For example, the output will be thesame if the engine is run every night or once a month. By maintainingmultiple Ledger Items, flexibility is allowed over time. For example, auser who wants to write a check number on LedgerItems when they are sentto payroll can do so.

[0140] Another feature of creating Ledger Items is the ability toimplement Draws. A Draw is when a Sales Representative is paid ahead oftime for expected sales. By creating a LedgerItem representing each ofthese payments, it is possible to use a reconciliation function to repaythe draw. Since the Engine always subtracts the total amount paid fromthe total amount which should have been paid, the next time the Engineis run, it will credit a LedgerItem debiting the amount of the Draw. Todelay the reconciliation, the “ignore” property on each Draw LedgerItemmay be set to True. (Transactions have a similar Ignore property,indicating that the Engine should not process them).

[0141] Effectivity Dating

[0142] One embodiment of the invention provides for effectivity dating.Effectivity Dating provides the ability to specify when specific Quotasand Promotions apply to specific individuals. Such an ability is usefulwhen a Sales Representative or Manager moves from one location toanother. Effectivity Dating ensures that the Representative's priorsales are taken into account at the new location in determiningPromotions that the Representative may receive.

[0143] Optimization to Performance

[0144] When discussing Engine performance, it is important to realizethat the design of the commission model greatly influences the time ittakes to process Transactions. Typically, performance is measured innumber of Transactions processed per hour, as the computation time willscale linearly in that parameter. In one embodiment a write transactionto a database occurs at the rate of 50-100 rows/second. When thousandsor millions of rows are written to a database, the data write can take aconsiderable amount of time.

[0145] Referring to FIG. 2, various model characteristics affectprocessing time including the Allocation 202 to Transaction 200 ratio(that is, the average number of people who are allocated credit for asingle sale), the Quota Detail 204 to Allocation 202 ratio (that is, theaverage number of “Quotas”, or performance metrics, to which eachAllocation applies), and the total number of Quotas 212 in a model.Commonly, the Allocation Ratio (A:T) is in the 3-8 range, the QuotaDetail Ration (D:A) is in the 1-6 range, and the number of Quotas rangeanywhere from 20-200.

[0146] In one embodiment three tables are utilized to store allTransactions: (1) a table for the base of all objects; (2) a table forthe base of commission objects; and (3) a table for the object itself.Whenever an Allocation or Quota Detail is created, a row is added to allthree tables. In one embodiment the commission object table iseliminated. By eliminating the use of one table, the number oftransactions stored on the databases are reduced by ⅓. In anotherembodiment, all three tables are combined into one table reducing thenumber of transactions on a database by ⅔.

[0147] In one embodiment of the invention, the least importanttransactions are delayed until a time when a computer processor isavailable for a large period of time (e.g., delayed until the weekend).The aspects of the invention that are used most frequently and must becurrent are the Quota State and Ledger items (i.e., the SalesRepresentative needs to have the ability to check the currentperformance level and total sales and the system needs to know how muchto pay a Sales Representative). To accomplish this delay withoutforfeiting the integrity of the data, three tasks are performed: (1)Accumulation; (2) Unpacking; and (3) Compensation.

[0148] Accumulation

[0149] Accumulation is also referred to as the mainline of oneembodiment of the invention. The Accumulation stage examines a set ofTransactions, changes/updates the Quota States and produces a set ofpackages. A package is a binary string consisting of a compressed groupof Allocations and Quota Details. One mechanism of a database that maybe utilized is the ability to save a Binary Large Object (BLOB) morerapidly than the group of objects corresponding to the single BLOB.Thus, a package may be rapidly stored in a database using the BLOBfunctionality. However, saving a BLOB has one disadvantage of disablingthe standard querying mechanisms of a database for those saved objects.

[0150] Unpacking

[0151] The Unpacking task loads all of the packages, creates therelevant objects (e.g., the Allocations and Quota Details) and saves theobjects to the database in the standard fashion. By delaying thecreation of the Quota Detail Objects and Allocations until a later date,the largest processing portion of the invention is delayed while theQuota States are still current.

[0152] Compensating

[0153] The Compensating task examines the Quota States and createsledger items (using the Promotion object). The Compensating task may beperformed prior to the Unpacking task.

[0154] By using the three tasks above, Sales Representatives may examinetheir current Quota States and receive timely and current payment(through the ledger items) while delaying the largest processing portion(i.e., the Quota Details and Allocations) until a large portion ofprocessing time is available (e.g., at night or on the weekend).

[0155] Parallelization

[0156] In one embodiment of the invention, the operations may be dividedbetween several computers. For example, the Quota Details creation andwrite transactions may be divided amongst several computers eachcreating a separate but linear table. Subsequently, the tables may beconcatenated together to create a single table for standard use.

[0157] In addition, the mainline computation can also be parallelized.If parallel processing (parallelization) is utilized for this purpose, afourth task of Aggregation is added to the three tasks discussed above.The Aggregation task aggregates all of the accumulated results on eachindividual machine into one table in the database. In such anembodiment, the ledger items are not activated for payment until theaggregation task has completed.

[0158] Thus, a method and apparatus for determining a commission isdescribed in conjunction with one or more specific embodiments. Theinvention is defined by the claims and their full scope of equivalents.

1. A method for determining commission using a computer system comprising: obtaining one or more transactions; obtaining one or more quotas that specify one or more levels; obtaining one or more promotions that specify a reward for one or more of said levels; calculating a performance of a recipient based on said transactions; determining if said recipient's performance qualifies for said promotion; and determining compensation for said recipient using said promotion if said recipient's performance qualifies.
 2. The method of claim 1 wherein said obtaining one or more transactions step comprises inputting one or more transactions into said computer system.
 3. The method of claim 1 wherein one of said quotas further specifies: a time period; a set of one or more eligibility rules; and a performance measure.
 4. The method of claim 3 wherein said performance measure provides the ability to quantify said transaction.
 5. The method of claim 3 wherein one or more of said eligibility rules determines whether one of said transactions applies to said quota.
 6. The method of claim 3 wherein said time period determines whether one of said transactions applies to said quota.
 7. The method of claim 1 wherein said reward comprises a mathematical formula.
 8. The method of claim 1 wherein said step of calculating a performance comprises: obtaining one or more allocations for said transactions; and adding an eligible allocation to a performance total.
 9. The method of claim 8 wherein said adding an eligible allocation step comprises: obtaining a change in performance based on said allocation; and adding said change in performance to a performance total.
 10. The method of claim 1 implemented in an object oriented environment.
 11. The method of claim 1 further comprising defining a property that may be used in said calculating step or determining steps.
 12. The method of claim 1 wherein said calculating performance step is executed using parallel processing on one or more of said computer systems.
 13. The method of claim 12 wherein said parallel processing comprises: accumulating one or more packages containing details regarding said recipient's performance using multiple processors; unpacking said packages into objects containing said details; saving said objects containing details; and aggregating said saved objects into one or more tables.
 14. The method of claim 8 wherein said obtaining an allocation step comprises processing an allocation rule that is based on one or more properties of a business.
 15. The method of claim 1 further comprising displaying a report of said recipient's performance.
 16. A system comprising a processor; a memory coupled to said processor; object code executed by said processor for providing at least one method for determining a commission; said object code comprising: a method obtaining one or more transactions; a method obtaining one or more quotas that specify one or more levels; a method obtaining one or more promotions that specify a reward for one or more of said levels; a method calculating a performance of a recipient based on said transactions; a method determining if said recipient's performance qualifies for said promotion; and a method determining compensation for said recipient using said promotion if said recipient's performance qualifies.
 17. The system of claim 16 wherein said method obtaining one or more transactions comprises object code comprising a method for inputting one or more transactions into said system.
 18. The system of claim 16 wherein one of said quotas further specifies: a time period; a set of one or more eligibility rules; and a performance measure.
 19. The system of claim 18 wherein said performance measure provides the ability to quantify said transaction.
 20. The system of claim 18 wherein one or more of said eligibility rules determines whether one of said transactions applies to said quota.
 21. The system of claim 18 wherein said time period determines whether one of said transactions applies to said quota.
 22. The system of claim 16 wherein said reward comprises a mathematical formula.
 23. The system of claim 16 wherein said method calculating a performance comprises object code comprising: a method obtaining one or more allocations for said transactions; and a method adding an eligible allocation to a performance total.
 24. The system of claim 23 wherein said object code for adding an eligible allocation comprises: a method obtaining a change in performance based on said allocation; and a method adding said change in performance to a performance total.
 25. The system of claim 16 further comprising object code for defining a property that may be used in said calculating method or determining method.
 26. The system of claim 16 wherein said method calculating performance is executed using parallel processing on one or more of said systems.
 27. The system of claim 26 wherein said parallel processing comprises object code comprising: a method accumulating one or more packages containing details regarding said recipient's performance using multiple processors; a method unpacking said packages into objects containing said details; a method saving said objects containing details; and a method aggregating said saved objects into one or more tables.
 28. The system of claim 23 wherein said method obtaining an allocation comprises object code processing an allocation rule that is based on one or more properties of a business.
 29. The system of claim 16 further comprising object code displaying a report of said recipient's performance.
 30. A computer program product comprising: a computer usable medium having computer readable code embodied therein for determining a commission, said computer program product comprising: computer readable code configured to cause a computer to obtain one or more transactions; computer readable code configured to cause a computer to obtain one or more quotas that specify one or more levels; computer readable code configured to cause a computer to obtain one or more promotions that specify a reward for one or more of said levels; computer readable code configured to cause a computer to calculate a performance of a recipient based on said transactions; computer readable code configured to cause a computer to determine if said recipient's performance qualifies for said promotion; and computer readable code configured to cause a computer to determine compensation for said recipient using said promotion if said recipient's performance qualifies.
 31. The computer program product of claim 30 wherein said computer code configured to cause a computer to obtain one or more transactions comprises computer readable code configured to cause a computer to input one or more transactions into said system.
 32. The computer program product of claim 30 wherein one of said quotas further specifies: a time period; a set of one or more eligibility rules; and a performance measure.
 33. The computer program product of claim 32 wherein said performance measure provides the ability to quantify said transaction.
 34. The computer program product of claim 32 wherein one or more of said eligibility rules determines whether one of said transactions applies to said quota.
 35. The computer program product of claim 32 wherein said time period determines whether one of said transactions applies to said quota.
 36. The computer program product of claim 30 wherein said reward comprises a mathematical formula.
 37. The computer program product of claim 30 wherein said computer code configured to cause a computer to calculate a performance comprises: computer readable code configured to cause a computer to obtain one or more allocations for said transactions; and computer readable code configured to cause a computer to add an eligible allocation to a performance total.
 38. The computer program product of claim 37 wherein said computer code configured to cause a computer to add an eligible allocation comprises: computer readable code configured to cause a computer to obtain a change in performance based on said allocation; and computer readable code configured to cause a computer to add said change in performance to a performance total.
 39. The computer program product of claim 30 implemented in an object oriented environment.
 40. The computer program product of claim 30 further comprising computer readable code configured to cause a computer to define a property that may be referenced by said computer readable code configured to cause a computer to calculate or computer readable code configured to cause a computer to determine.
 41. The computer program product of claim 30 wherein said computer readable code configured to cause a computer to calculate performance is executed using parallel processing on one or more of said computer program products.
 42. The computer program product of claim 41 wherein said parallel processing comprises: computer readable code configured to cause a computer to accumulate one or more packages containing details regarding said recipient's performance using multiple processors; computer readable code configured to cause a computer to unpack said packages into objects containing said details; computer readable code configured to cause a computer to save said objects containing details; and computer readable code configured to cause a computer to aggregate said saved objects into one or more tables.
 43. The computer program product of claim 37 wherein said computer readable code configured to cause a computer to obtain an allocation comprises computer readable code configured to cause a computer to process an allocation rule that is based on one or more properties of a business.
 44. The computer program product of claim 30 further comprising computer readable code configured to cause a computer to display a report of said recipient's performance. 